1. Field of the Invention
The invention relates generally to resource access synchronization in computer systems.
2. Description of Related Art
In a multi-threaded programming environment, there is often a need to serialize the access to a shared resource. Sometimes it is also necessary that the individual threads access the resource in the order in which they have requested access.
One method of achieving serialization is through the use of a mutex lock. A mutex is a class of object in a computing environment that enables mutual exclusion support. It is used to ensure serialization of access to a resource by acquiring and releasing a lock on that resource. At any one time only one method or function can “lock” the resource. A mutex has two pieces of state, a lock bit and a queue of function/argument pairs defining methods or functions waiting to acquire the lock. Thus, a mutex enables the resource to be allocated to a single requesting thread at a time. However, the manner in which mutexes are implemented does not guarantee that a lock will be acquired by a thread in the order in which the threads have requested access to it.
An example of a situation where it is necessary to serialize access to a shared resource in such a manner that access to the resource by individual threads is permitted in the order in which the access has been requested, is in the context of a server that handles requests with multiple threads. Requests usually involve access to server resources. If several requests concerning the same resource arrive in a specific order, then the correct behavior is to access the resource sequentially (thread serialization) and in the same order (order preservation).
Consider an example of a print server that receives the following requests:    1. Create a job on a printer;    2. Add document 1 to the job;    3. Add document 2 to the job;    4. Print the job.
The threads that handle those requests must clearly have access to the printer resource in the required order in order that the job is handled in the correct manner. If a mutex is provided to protect the printer resource, this will be set by the thread that currently has control of the printer resource. As the “create a job” thread is the first to make a request for the printer resource, the “create a job” thread will initially lock the mutex and gain control of that resource. While the “create a job” thread is active, any subsequent thread that request the resource will be blocked on that mutex. When the first request (i.e. the “create a job” thread) has completed its action, the next thread that acquires the lock on the mutex will not necessarily be the “add document 1” thread. This is because conventional mutex control does not provide any access ordering. Accordingly, if the “print job” thread were the next thread to lock the mutex, a job would be printed before any documents have been added to the job.
In order to address this, the classical solution to controlling the order of access to the resource is to introduce a task object. Individual tasks can then be put in a queue, and can be activated by a task manager in the correct order. In such an example, each time a resource requests an access to a resource, a separate task object is created, and the task object is put in a queue in the order in which the requests are received. A separate thread will act as a process to control the order in which the individual task objects are activated to carry out the tasks concerned.
However, such a solution requires a significant overhead in the amount of programming code necessary for implementation.
Also, it is to be noted that servers are often implemented using a framework that operates across platforms, gives no control on the way that the threads handle requests and provides a unified interface for various platform specific mutex implementations.
Accordingly, there is a need for a more efficient solution to the provision of serializing thread access to resources, with access order preservation.